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(54) TItte: ELECTRONIC PAYMENT METHOD FOR PURCHASE-RELATED TTlANSACnONS OVER A COMPUTER 

^^^^"^^ ?ES?5R^tS^S^ 
(57) Abstract 

A method using an open communication 
network (10) to which retailer server stations 
(20) and customer stations (30) are connected. 
According to the method, a retailer server station 
generates a payment slip for the planned purchase 
transaction between the retailer and a customer, 
which slip comprises data on the retailer, the 
customer, the purchased item or service and 
the price; the payment slip is transmitted over 
the network to a payment server station (40); 
the payment server automatically checks whether 
tile payment of said price is authorised for the 
customer in question, by querying the client's 
personal account set up in the payment server 
for paying small amounts, or, in the case of 
larger amounts, by making a query over a banking 
network (50) separate firom the computer network 




ii?*/ the payment is authorised, the payment server generates a cash voucher comprising at least some of the data 
and the cash voucher is transmitted to the retailer to enable the purchase to go ahead. 



on the payment slip; 



(57) Abr^^ 

Lc proc^dtf utilise un rtscau dc communication ouvcrt (10) sur lequel sont coimect6s dcs postes scrvcure dc maichands (20) ct dcs 
Dostes clients (30) ct comprend: T^laboration par un postc scrvcur dc maichand d'un ticket dc paicmcnt, conccmant un achat envisage cntre 
le maichand ct un cUcnt, ct comportant dcs informations relatives au marchand, au client, ^ Tobjct dc Tachat ct h son prix; la transmission 
du ticket dc paiement via Ic rtscau k un postc scrvcur dc paicmcnt (40); la verification automatique par Ic scrvcur dc paicmcnt si Ic paicmcnt 
du Prix est autoris6 pour le client conccmf, soit par intenrogation d'un comptc client propre au client, tcnu par le scrvcur dc pmemcnt, ct 
dcstin6 au paicmcnt des pctits montants, soit par interrogation sur un r^u bancaire (50) inddpcndant du rtscau infoimauquc (10). pour 
Ics paiemcnts dc montants plus 61cv6s; si la verification est positive, reiaboration par le scrvcur dc paiement d»un bon dc caisse comportant 
au moins une paitie dcs informations du ticket dc paicmcnt; ct la transmission du bon dc caisse au scrvcur dc marchand afin d autonser la 
realisation dc TachaL 
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Proc^de de paiement ^lectronique permettant d'eflectuer des transactions Hies 
k rachat de biens sur un r£seau informatique 

La pr6sente invention conceme un pioc^e dc paiement diectionique 
5 permettant d'effectuer des transactions lides k I'achat dc biens offeits par des 
maichands au moyen de services t£16matiques via un r6seau de t£I^mmunication 
informatique ouvert sur lequel sont conncctfis des postcs serveure de marchands et 
des postes clients. 

Par r6seau infoimatique ouvert, on entend ici un reseau sur lequel des 
10 particulicrs ou des entreprises peuvent librcmcnt sc connecter a la condition dc 
disposer d'une adiessc, par exemple le reseau "Internet". Les biens conccmis sont 
des produits ou des services, dont la foumiture est r6alis^ hors du r&eau aprfes la 
conclusion de la transaction, ou des biens immatiriels, tels que des informations, 
dont la foumiture peut etrc r^alisie via le reseau infomiatiquc. 

Divers proc6d6s de paiement ^lectronique ont 6t6 proposes, certains 
£tant d6ja op6rationncls. 

Plusieurs proccdfis sont fondds sur une nouvelle representation dc la 
monnaie. II s'agit d'une representation ilectronique, quelqucfois dcnommcc "jeton" 
qui peut 6tre purement logicielle ou partiellement matirielle, par exemple avec une 
carte h puce. Ces proc^ds impliquent la circulation de monnaie sur le r€seau 
infomiatique, ce qui pose des problimcs difficiles de securitd vis-a-vis de la 
creation de fausse monnaie. 

D'autres proc6des connus de paiement 6iectronique impliquent une 
relation directe avec une banque ou un rfceau bancaire. Typiqucment, de tels 
procidcs sont employis dans les r6seaux dc carte de ci6dit comme. par exemple, 
des procidds bien connus utilisant des tcnninaux points de vcnte relics a un circuit 
carte bancaire ainsi que des proc6d6s utilisant des ch&ques ilectroniques avec une 
signature ilectronique pour Tauthentification de I'acheteur. Cest une fonne de 
lettre d'engagement dmise par un acheteur, remise au vendeur et acceptde et 
30 reconnue par une banque. 

Les proc^dds qui impliquent k un moment ou un autre dc la transaction 
une relation avec le systdme bancaire traditionnel et la mise en oeuvrc d'une 
transaction dans ce systfeme pifscntent des inconv6nients. Ainsi, les transactions 
dans le systimc bancaire ont un cout rfel qui devicnt prohibitif lorequc le montant 
35 de I'achat est trte faible, par exemple un m ntant associ6 h la consultation d'une 
base de donn6es. Or, les rfiseaux infonnatiqucs sont bien adaptds h la vente de 
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bicns dc faiblc valeur, prindpalement dcs bicns d'information, puisquc la livraison 
du bicn pcut sc faire par Ic r6seau lui-mcmc. En outre, Tacccs a un r6seau bancairc 
ou un rcscau dc carte bancairc doit ctre hautcmcnt prot6g6, cc qui cxclut 
pratiquement la possibilit6 d'un accte a travcrs un rfacau informatique ouvcrt, tcl 
5 que Ic r£seau •"Internet'* sur lequel des acheteuis potcntiels pcuvcnt sc connecter. 

L'invcntion a pour but de foumir un proc£de pcrmettant d'6viter les 
inconv6nients dcs proc£d6s connus, en particulier un proc£d6 pcrmettant, sans 
circulation de monnaie 6lectroniquc, dc r6aliser de fa^on simple ct fiable des 
transactions li6es a I'achat de bicns sur un rcscau informatique, ct cc aussi bicn 
10 pour dcs bicns dc prix elevd n^ccssitant une autorisation par Ic systeme bancairc 
traditionnel, que pour des bicns de faiblc ou tres faiblc prix. 

Cc but est atteint grace a un proc£dc du type defini en tete de la 
prescnte description ct comportant, confonnement a I'invention, les 6tapcs de : 

- Elaboration par un poste scrveur de marchand connect^ au r6scau 
15 d*une demande d'autorisation de transaction, ou "ticket dc paiement", concemant 

un achat envisag6 entre le marchand et un client, ct comportant des informations 
relatives au marchand, au client, h I'objet de Tachat et a son prix, 

- transmission du ticket de paiement via le rcscau informatique a un 
poste scrveur de paiement distinct des postes clients ct serveurs de marchands, 

20 - verification automatique par le scrveur dc paiement si le paiement du 

prix est autorise pour le client concera6, la verification itant e£fectu6e, scion le 
montant du prix a payer, soit par interrogation d'un compte proprc au client, tenu 
par le scrveur dc paiement, et destine au paiement dcs petits montants, soit par 
interrogation sur un r6seau bancairc inddpendant du r^seau informatique, pour les 

25 paiements de montants plus £lev6s, 

- si la verification est positive, Elaboration par le scrveur de paiement 
d'une autorisation dc transaction ou bon de caisse comportant au moins une partie 
dcs informations du ticket de paiement, et 

- transmission du bon de caisse au scrveur de marchand via le r6scau 
30 informatique, afin d'autoriscr la realisation dc Tachat. 

Ainsi, le proc£d6 scion Tinvcntion est remarquable en cc qu'il 
n'implique ni la cr6ation de monnaie ilectroniquc, ni la circulation dc monnaie 
eicctronique sur le r6seau informatique. 

La gestion dcs transactions est effectu6e par un scrveur dc paiement 
35 qui seul pcut accEder a un rcscau bancairc ou un rdscau dc carte bancairc, et qui 
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gcrc des comptes clients non bancaircs sur lesqucls dcs transactions de faibles 
montants peuvent ctre effectudes. 

Le servcur de paiement gferc cgalcment des comptes marchands non 
bancaircs utilises pour ies transactions de faibles montants. Ainsi, lorsqu'un bon de 
caisse est transmis aprte vdrification par interrogation d'un compte client tenu par 
le servcur de paiement, le montant de I'achat est d£bit€ du compte client et cr^ditd 
sur un compte marchand proprc au maichand concemi et tenu par le servcur de 
paiement, ce qui n'entraine pas des couts de traitement 61cv&. 

Chaquc client dispose d'unc idcntit6 qui lui est propre pour pouvoir 
utiliscr Ic proc6d6 de paiement. II doit 6galemcnt disposer d'un compte bancaire 
i^cl, de pr^Krcnce un compte utilisable au moyen du systeme tiaditionnel des 
cartes bancaircs. La verification par le seiveur dc paiement peut comprendic une 
phase pr^alable dc validation de I'idcntiti du client h partir du contenu du ticket de 
paiement. La validation de I'identit6 est une operation prialablc h I'accis 6vcntuel 
au compte du client, si Ic montant de I'achat est faible, et/ou a I'acccs au icscau 
bancairc si le montant est plus 61cv6. Le servcur dc paiement comporte de 
preference dcs moycns, par cxemple une base dc donn6es, permcttant dc 
m6monscr Ics relations cntic les identity des clients utilis6es pour les transactions 
sur le riscau informatique et des identity bancaircs (num6ios de comptes 
bancaircs ou numdros de cartes dc crddit) utilis6cs pour les transactions sur Ic 
i^scau bancairc. On peut ^vitcr de la sorte la circulation d'identit& bancaircs sur ic 
i^scau informatique. 

Un mode de realisation de IWntion seia maintenant decrit h titrc 
indicatif, mais non limitatif. en r6f6rcncc aux dessins anncx& sur lesqucls : 

- la figure 1 est une vue g6n6ralc trfes sch6matiquc d'un systeme de 
paiement 6Iectroniquc confonne k Tinvention ; 

- la figure 2 est une reprdscntation sous forme d'un schdma bloc d'un 
servcur dc paiement du systimc de la figure 1 ; 

- figure 3 iWustre le dfroulemcnt des operations relatives h un achat 
30 au moyen dusystdmede la figure l;et 

-les figures 4A k 4C sont des organigiammes montrant tris 
schdmatiqucment les operations effectuees par le servcur de paiement. 

Sur la figure 1 est rcpresente de fagon tris schematique un rdscau d 
telecommunication informatique 10 sur Icquel sont corniectds des postes scrveuis 
dc marchands 20, dcs postes clients 30 et au m ins un postc servcur de paiement 
40. 
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Lc i€seau informatique 10 est un r6scau ouveit ou public, par exemplc 
le r€seau d6noiiun6 "Internet". 

Les seiveure de maichands 20 sont des unites telles que cclles 
couramment utilisdes pour des serveurs tclimatiques connectcs sur "Internet", par 
5 excmple des unites organis^es autour de machines "Unix" multiprocesseuis. 

Lcs postes clients 30 sont essentiellcment des micro-ordinateurs qui 
sont munis de moycns de connexion au reseau "Internet" 10, par exemple sous 
forme d'interfacc "Web". Les serveurs de marchands 20 et de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "World Wide 
10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, montrd avec plus de details sur la figure 2, 
comprend des unit6s ftontale ct dorsalc respectivement 41 ct 42 connectees toutes 
lcs deux au i^seau "Internet" 10. L'unit6 firontalc 41 a une architecture scmblable a 
ccUe d'un serveur classique connecte sur un r6seau tel qu'"Intemet"". L'unit6 
15 doisale 42 comporte une unite de traitement 43 k un ou plusicurs proccsscuis, une 
base de donn6es 44 comportant des informations relatives aux marchands et clients 
abonn6s au systfeme de paiement, un rcgistre de transactions 45, une unite 46 
d'interface avec un reseau bancaiie ou un r6scau de carte bancaiie 50, et un bus de 
communication 47 ou autre liaison similaire permettant de relier entrc eux lcs 
20 diff6rcnts constituants de I'unitd doisale 42. Une liaison sccuiisee 48 pcrmet une 
communication bidirectionnelle entrc I'unitd frontale 41 et I'uniti de traitement 43. 
La communication avec le r6seau informatique 10 est contr616c par I'uniti frontale 
41 tandis que la gestion de la base de donnees 44 ainsi que le contr61e de la 
communication avec le r6seau bancaire 50 sont assures par runit6 doisale 42. 
25 La base de donndes 44 contient des infonnations relatives aux clients 

et aux maichands abonnds au systeme de paiement. Poui chaque client, la base de 
donnees 44 contient I'identitd systime du client ("CId"), identity le^ue lors de 
I'abonnement au systime, un compte de client ou porte monnaie ilectronique 
("PME") destind au paiement de faibles montants, une identit6 bancaire telle que 
30 numdro de compte bancaire rdel ou numdro de carte de crddit ainsi 
qu'dventuellement une clef d'acces ou mot de passe propie au client. Pour chaque 
marchand, la base de donn6es 44 contient I'identitd systeme du marchand ("Mid"), 
identitd rc9ue lots de I'abonnement au systfeme, un compte de marchand, ou tiroir- 
caisse dlcctioniquc ("TCE") dcstini h rencaissemcnt des faibles montants et une 
35 idcntite bancaire telle que numdro de compte bancaire rdel. 
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La figure 3 illustre schcmatiqucmcnt Ics diffdrentes 6tapes d'une 
transaction pottant sur un achat d'un bicn par un client abonnfi a un maichand 
abonne. U peut s'agir d'un bicn materiel dont la livraison au client sera effectudc 
r6ellemcnt aprte conclusion dc la transaction ou d un bicn immatdriel (tel que de 
5 I'information) qui peut etrc foumie au client par le reseau informatique des le 
paiement £lectronique effectue. 

m Consultation par le client 

Par connexion sur le r6scau "Internet" 10, un client peut consultcr cn 
ligne le catalogue ou la "vitrine" d'un marchand quelconque par acces au scrveur 
10 20 du marchand et par visualisation sur I'^cran du postc client 30 des biens ou 
services du marchand. Sur pr6sentation de I'identite CId du client, le scrveur du 
marchand peut pr6senter au client des conditions financiferes particuliferes (par 
excmple une remise) applicables a la transaction iventuelle. 
g^Demanded'arhflt 

^ choix du client itant arTet6 sur un bien O, il est transmis au scrveur 
du marchand sous forme d'un message contenant une identity Old du bien et 
I'identitd CId du client. Loisque cela est necessaire, par exemple pour la livraison 
ultcrieure du bien choisi, des informations compldmcntaiies (par exemple une 
adrcsse et un horaire de livraison pr6f6r6). Cela peut etrc r6alis6 de fa^on 
20 commode en utilisant un fonnulaire dlectronique envoys sur le reseau et destini a 
etre rerapli par le client. 

Dans le cas ou I'achat envisag6 rcpr6sente un montant 61ev6 ou est 
soumis k des conditions Idgalcs, une authentification prialable du client peut etre 
souhaitte. COmme on le vena en detail plus loin I'authentification d'un client est 
25 effectute par le serveur de paiement 40. Aussi. une demande d'authentification 
provcnant d'un marchand est 6mise avantageusement sous la forme d'un ticket de 
paiement de valeur nuUe qui est transmis au serveur de paiement par le reseau 
informatique via le poste client et, cn cas d'authentification positive, provoque le 
retour d'un bon de caissc du serveur de paiement au serveur marchand, toujoure via 
30 le poste client. Les proc£duies d'^tablissement d'un ticket de paiement et de renvoi 
d'un bon de caisse sont d6crites plus en detail ci-apr^s. 

La demande d'achat imise par le client peut porter sur un scul bien ou 
sur plusicurs biens k foumir de fagoa groupie : "achat panier". 
(3) Elaboration de la demandr. ,\ f nairmrt^^ 

^ rfponse a une demande d'achat, le serveur marchand 61abor une 
demande dc paiement qui peut comprendrc les informations suivantes : 
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- Idcntitd du marchand, ("Mid"); 

- Description du bicn cx)mmandc, ou dc chacun dcs bicns du panier, cn 
cas d*achats group^s; 

- Type dc transaction (simple ou panier); 
5 - Identity du client, ("Cld"); 

- Identity du bicn ou dc rensemblc dcs bicns du panier, ("Old"); 
-Prix dc robjct,COid"); 

- TVA (si applicable); 

- Date ct hcure dc remission du ticket dc paicmcnt (horodatage par Ic 

10 scrvcur marchand); 

- Durce dc validit6 du ticket dc paicmcnt; 

- Numcro de s6ric dans le registrc dcs vcntes du marchand (notamment 
dans le cas ou la transaction a comport6 unc ctapc prcalable d'authentification). 

Uenscmblc dcs informations ci-dessus est cncodde dans unc chainc 
15 d'octets qui constitue la chainc opaque d'un ticket dc paicmcnt (ou URL de 
commande dc bicn, URL 6tant Ics initialcs dc "Uniform Resource Locator" ou 
Localisateur dc Ressourcc Uniforme utilise dans Ics logicicls WWW avcc 
protocole HTTP), comme suit: 

URL http : < SP> < descriptif dc la commando , 
20 oil SP est I'adrcsse "Internet" du scrvcur de paicmcnt. Le ticket de paicmcnt est 
adrcsse au poste client. U est complete par deux "ancres" logiqucs qui pcrmcttent 
au client soit de Tannulcr, soit dc le confirmer. 

U\ f nvoi de Tor dTC de paicmcnt 

Uordrc de paicmcnt est transmis au scrvcur dc paicmcnt simplemcnt 
25 par validation par le client dc TURL dc dcmande dc paicmcnt. On comprcndra 
bicn que Ic ticket de paicmcnt nc fait alors que transiter par le poste client. 

Sur reception d*un ordre de paicmcnt, le scrvcur dc paicmcnt 40 le 
decode ct procfede a lauthentification du client ct recherche si le paicmcnt peut ctre 
30 autorise avant dc rctoumcr un bon dc caissc ou un refus dc paicmcnt. 

Les operations tfauthcntification dc client et d'autorisation de paicmcnt 
scront decrites plus loin cn detail en reference h la figure 4. 

Lorsque les verifications cffcctuccs nc pcrmcttent pas d'autoriser le 
paicmcnt, unc notificati n de refus motivdc est adrcss6c au client par Ic scrvcur de 
35 paiem nt (indiquant, par cxcmplc, comptc insuffisammcnt approvisionn6, 
dipasscmcnt d'un scuil autoris£ pour le client, ...) 
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Lorsque Ics v6rifications cffcctu6cs pcrmcttcnt d'autoriscr Ic paicmcnt, 
les informations contcnucs dans Ic ticket dc paicmcnt sent completes avcc un 
numcro dc s6ric dans Ic rcgistrc des transactions 45, une cstampillc horaire, unc 
durdc de validity (typiquemcnt quclqucs dizaincs dc sccondcs) ct Ic sccau du 
5 scrvcur dc paicmcnt constituant unc information dc certification. L'cnscmbic dc 
CCS informations, ivcntucllcmcnt apits signature num6riquc par I'utilisation de la 
paitic dc clef priv6c d'un systcme de chiffrement k clef priv6e/clcf publique du 
scrvcur dc paicmcnt (ce qui garantit la validity ct I'intfigritc dc I'autorisation dc 
paicmcnt), est cncod6 dans unc chainc d'octets qui constitue la chaine opaque d*un 
10 bon dc caisse ou URL dc livraison : 

URL http : <M> <dcscriptif du bon de caisse> , 
ou <M> est I'adresse "Internet" du maichand. 

(6) E>emande de !ivra|<:^j] 

Lc bon dc caisse est transmis au scrvcur du marchand via Ic postc 
15 client. Ceci pent ctre effcctu6 automatiqucment par le logicicl implantc au postc 
client en utilisant la possibility dc rc-routagc des URL bicn connue de I'homme du 
metier. Avant d'autoriscr la livraison du bicn, lc scrvcur du marchand opere un 
dccodagc ct une verification du bon dc caisse rcgu. Cctte verification consiste a 
utiliscr la clef privdc 6vcntucllc du scrvcur de paicmcnt, a verifier que la durcc de 
20 validite n'est pas ecoulce, ct k rapprocher lc contcnu du bon de caisse avcc celui dc 
la demande dc paicmcnt. 

m Livraison du hien 

Lorsque le bon dc caisse est valide par lc scrvcur du marchand, celui- 
ci pcut cffectuer la livraison dircctc sur lc postc client, dans le cas de bicn 
25 d'information, ou adrcsse au postc client un document permcttant le ictrait du bicn 
ct prficisant notamment le lieu de livraison ct lc nom du rccipicndaire. 

On notera que, dans le cas d'un achat group6 (panier), il y a creation 
par lc scrvcur du marchand d'un objet avcc affectation d*une idcntite unique. Get 
objet est la listc des URL de chacun des biens du panier. Cest cet objet qui est 
30 indique dans lOJRL de commande de bicn ct qui permettra dcnregistrcr le detail 
des biens achctes dans lc rcgistrc dc transaction du scrvcur dc paicmcnt. 

Les figures 4A a 4C montrent les operations effectuees par le scrvcur 
dc paicmcnt 40 en reponsc h la reception d'un ordrc dc paicmcnt. 

Dans I'unite fiontalc 41 (figure 4A), rordic dc paicmcnt est decode 
35 (etape 61) ct sa validite est examinee (test 62) notamment du point de vue dc la 
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dur6c dc validit6. Si Ic i6sultat de I'cxamen est ncgatif, unc notification dc refiis est 
cnvoyce au postc client (6tapc 63). 

Si le i^sultat dc I'cxamen est positif, il est pioc6d6 cnsuite a une 
authentification du client (6tape 64), le d6tail dc cette operation 6tant d6crit plus 

5 loin cn rffdrcnce I la figure 4C. Si I'authcntification est ndgativc (test 65), unc 
notification de refus est envoyte au client (6tape 63). Si ellc est positive, I'ordre dc 
paiement (dvcntuellement limitd a I'identit^ Od du client, a ridentit6 Mid du 
marchand, et au prix) est transmis via la liaison 68 a I'unite doisalc 42 du scrvcur 
dc paiement lepr&entd sur la figure 2 (6tape 66). La liaison 48 est unc liaison 

10 sccurisec interdisant I'accfes h I'unitc dorsale a toute pereonne se conncctant sur le 
rescau 10. 

L'unitd frontalc 41 attend alors que I'unite dorsale dfcide d'autoriscr ou 
non le paiement (^tape 67). Si le paiement n'est pas autorisd, (test 68). unc 
notification de refus est cnvoyce au postc client (6tapc 63). Si le paiement est 
15 autorisi, un bon dc caisse est filabori (etapc 69). utilisant les informations 
enrcgistrfies a I'dtapc 62. Le bon dc caisse est cniegistrfi dans unc mcmoirc dc 
l'unit6 fiontalc 41 (etapc 70) et est adicss6 au servcur du marchand via le postc 
client (6tape 71). 

Au niveau dc I'uniti dorsale 42 (figure 4B) du scrveur de paiement, h la 
20 riception d'un ordrc dc paiement authentifid, il est examin6 si cclui-ci doit ctre 
autoris6 a partir du compte client PME via le r6seau bancaire 50. A cet effet, le 
prix est compart a un seuil minimum (test 72). Ce scuil est par cxcmplc de 
quelques dizaines de fi-ancs. 

Si le seuil est dcpassd, unc dcmandc pour cffcctucr I'opcration de 
25 paiement est lanc6c sur Ic rfecau bancaire (6tape 73) en utilisant I'identite bancaire 
correspondant a l'identit6 CId du client, telle qu'elle ressort de la consultation de la 
base dc donn6es 44. A la idccption de la riponse positive ou negative (dtapc 74), 
ccllc-ci est transmise h I'unitd frontalc 41 (6tapc 75). 

Si Ic scuil n'est pas d6pass6, le paiement pcut ctre effectu6 a partir du 

30 compte PME du client. 

A cet effet, il est examin6 si le compte est suffisamment approvisionn6 
(test 76). Dans la negative, un refus d'autorisation de paiement, c'est-a-dire une 
r6ponse negative, est renvoy6c h l'unit6 frontale (6tape 75). Dans raffirmativc. le 
compte PME du client est d€bM du prix et 1 compte TCE de marchand 

35 correspondant i I'identiti Mid est cr6dit6 du meme montant (dtope 77), la 
transaction est inscrite dans le registre des transactions 45 (6tapc 78) et 
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I'autorisation dc paicmcnt, c'est-a-dirc une rfponse positive est txansmisc h VuniU 
frontale 41 avec I'indication du num^ro dc sdric de I'inscription dans ie registre dc 
transactions (etape 75). 

La pioc6dure d'authcntification dans Ic scivcur dc paicmcnt (figure 
4Q, h l'6tapc 64 de la figure 4A, comprend I'envoi au poste client, dc pr6«rencc 
dans une foimc s6curisic (chiffrfc), d'unc demandc de cl6 d'acccs, ou mot dc passe 
(6tape 641). A la reception s^ris6e de la cl6 d'acces (6tapc 642), une comparaison 
est effectu6c avec une information conespondantc contenue dans la base de 
donn^es 44 (test 643). 

Si la comparaison est negative, et qu'un nombrc maximum dc 
tcntatives infructucuscs n'a pas 6t6 attcint (test 644), on retoume h Vitapc 641. Si ce 
nombre maximum est attcint, I'absence d'authcntification est constat€e, une alerte 
est produitc (itape 645) ct une rcponsc negative est envoyee au poste client (6tape 
646). L'alerte pcut consister cn une annulation du compte PME ou cn une 
15 surveillance dc cclui-ci afin de ddtccter dc nouvcUes tcntatives d'utilisation. Si Ic 
test a I'dtape 643 est positif, I'authcntification est enregistrfc (6tape 647) ct une 
reponse positive est ^laborec (6tape 648). 

DCS techniques de chiffrcment penncttant la transmission s6curis6e 
d'informations num6riqucs sur rcscau infonnatiquc, notammcnt pour la demandc 
20 d'envoi dc cl6 d'accis ct I'envoi dc ccUc-ci. sont bien connucs. 

La procedure d'authcntification ddcrit ici permct d'cffcctucr une 
authentification pr6alable d'un client dans Ic cas ou cellc-ci est n6ccssaire avant 
r^tablissemcnt d'une demandc dc paicmcnt par Ic serveur du marchand. Pour ccttc 
authentification, il suffit alois en effet de crcer un ticket de paiement dans lequcl Ic 
25 prix indiqu6 est nul, comme indiqu6 plus haut. 

L'enregistrcment des bons de caisse dans I'unitfi frontale permct aux 
clients ct aux marchands dc procddcr h des contrdlcs et d'en obtcnir 6vcntuellemcnt 
dcs copies. L'cmegistrement des transactions dans I'unitd dorsale permct d'en 
conserver une trace cn cas, par exemplc, de contestation entrc un client et un 
30 marchand. 

Les comptes clients PME g6r€s par Ic serveur de paiement ont en 
principe un montant dc solde plafonn6 ct. selon Ic mode dc realisation pr<f6re dc 
rinvention, ils ne sont pas r6muner6s (le systimc dc paiement sc trouvant en 
dehors du mondc bancairc). Un rdappiovisionnemcnt de son compte PME par un 
35 client pcut ctre e£fcctu6 a partir de son compte bancairc. par ordre donnd a son 
etablissement bancairc. 
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Ixs comptcs marcbands TCE ger6s par le scivcur dc paicmcnt sont 
associds a dcs comptcs bancaires reels dcs marchands dans lesquels ils sont vid6s 
par exemple quotidiennemcnt. 

Bicn que Ton ait ddcrit ci-avant un mode de misc cn ocuvrc d'un 
5 proccdc selon rinvcntion dans un cnvironnemcnt "Internet" ct avec des logiciels 
WWW utilisant le protocolc HTTP, rhomme de Tart comprcndra aisiment que le 
procdde peut ctrc mis en ocuvrc avec un rcscau informatiquc autre qu'^Intcmet" ou 
encore avec des logiciels servcur marchand et client n*utilisant pas le protocolc 
HTTP de WWW. En outre des procedcs d'authentification securis6s mcttant cn jcu 
10 dcs dispositifs mat6ricls tels que lectcur de carte a puce ou moycn de 
reconnaissance d'empreinte vocale pourront ctre prcvus a la place dc clcfe d'acc^. 
Ces demicres ct d'autrc modifications qui vicndront a Tesprit du rhomme du metier 
sont comprises dans la philosophic ct la portce dc la presente invention. 
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REVENDICATIONS 

1. Procdd6 dc paiemcnt ^Icctronique pour des transactions li6es k I'achat 

dc biens offcrts par des marchands k des clients via un r&eau infonnatique ouvert 
sur iequel sont conncct6s des postes scrveure dc marchands et des postcs clients, 
S caracterisi par les Stapes de : 

- 61aboration par un poste scrveur dc marchand connects au i€scau 
d'une demandc d'autorisation de transaction, ou ticket de paicment, concemant un 
achat envisage cntre le marchand et un client, et comportant des infonnations 
relatives au marchand, au client, k I'objet de I'achat et a son prix, 

- transmission du ticket de paiemcnt via le r6seau infoimatique a un 
scrveur de paicment distinct des postcs clients et serveurs de marchands, 

- verification automatique par le scrveur de paicment si Ic paicment du 
prix est autorise pour le client concern^, la verification 6tant e£fectu6c, scion Ic 
montant du prix a payer, soit par intenogation d'un comptc client pioprc au client, 

15 tcnu par le scrveur de paicment. et destine au paiemcnt des pctits montants, soit par 
interrogation sur un r6seau bancairc ind€pendant du r6seau informatiquc, pour Ics 
paiements de montants plus eiev6s, 

- si la verification est positive, Elaboration par le scrveur de paiemcnt 
d'une autorisation de transaction ou bon de caissc comportant au moins unc partic 

20 des informations du ticket dc paiement, et 

- transmission du bon de caissc au scrveur dc marchand via le reseau 
infotmatique, afin d'autoriser la r6alisation de I'achat. 

2. Proc6d6 selon la rcvendication 1, caractcrise en cc que lorsqu'un bon 
de caisisc est transmis aprfes verification par intenogation d'un comptc client tcnu 

25 par le serveur de paicment. le montant de I'achat est d6bite du comptc client et 
credite sur un comptc marchand propre au marchand conceme et tenu par le 
scrveur de paiement. 

3. Procede selon I'une quelconque des revendications 1 et 2, caractdrise 
en ce que la verification par le scrveur de paiement comprcnd unc phase prdalable 

30 d'authentification du client. 

4. Precede selon la revendication 3, caracterise en ce que 
I'authentification est rdalisec par reconnaissance d'une clef d'accis transmise par Ic 
reseau informatiquc du poste client au scrveur de paiemcnt. 

5. Precede selon Tunc quelconque des revendications 1^4, caracterise en 
ce qu'il comprend I'eiaboration par le scrveur dc paicment d'un bon de caissc 
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compoitant au moins une partic des infonnations du ticket de paiement et une 
infoimation de certification. 

6. Proc6de selon Tune quelconque des levendications 1 a S, caracterise en 
cc qu'il comprend la mdmorisation par le servcur de paiement des transactions 

5 autorisees, par stockage d*au moins une paitie du contenu des bons de caisse. 

7. Pioced6 selon Tune quelconque des revcndications 1 a 6, caracterise en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur de 
paiement par Tinterrnddiairc du postc client. 

8. Proccd6 selon I'une quelconque des revendications 1 a 7, caract6risc en 
10 cc que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par Tintermediaire du poste client. 

9. Systcme de paiement 6lectronique pour effectuer des transactions lices 
a Tachat de biens offerts par des marchands a des clients via un r£seau informatique 
ouvcrt, le systfemc comportant des postes clients et des postes servcurs dc 

IS marchands pouvant ctre connect6s sur le r6scau ouveit, 

systcme caract£ris£ en ce qu'il comporte en outre au moins un poste servcur de 
paiement distinct des postes clients et serveuis de marchands et comprenant : 

- une unit6 frontale munie de moyens de connexion au r£seau ouvert, 

- une unit£ dorsale munie de moyens de connexion a un reseau 
20 bancaire independant du reseau ouvert, 

- des moyens de communication entre les unit6s frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
foumisseurs, et 

- des moyens de traitement pour, en reponse k la reception par Tunit^ 
25 frontale d'une demande d*autorisation de transaction ou ticket de paiement, 

concemant un achat envisage entre un marchand et un client, v6rifier si le paiement 
du prix est autoris^ pour le client concern^ par interrogation du compte du client 
ou du reseau bancaire et, si la verification est positive, 61aborer une autorisation dc 
transaction, ou bon de caisse afin de la transmettre sur le r6seau ouvert via lunitd 
30 frontale. 

10. Systcme de paiement scion la rcvcndication 9, caract^ris^ en ce que le 

servcur de paiement comprend des moyens de memorisation des transactions 
autoris6es. 
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